Here are a few ideas on topics which have caused problems in the past. I think there may be an opportunity to affect an improvement, so here are a few suggestions.
Suggestion for runtime environment.
As I understand it, dennis_glatting@trirex.com is going to provide the runtime environment for the Objective-C. As one who has developed an Object inspector which displays the runtime information of any object, let me strongly recommend that the access to the runtime environment be object oriented. NeXT's set of runtime functions and non-object-oriented data structures made my job much harder than it needed to be. Had the runtime itself been object oriented, building an object inspector would have been a no-brainer. More importantly, future enhancements to the runtime system would go smoother if it were object oriented.
If its too late to go object oriented with the runtime environment (for whatever reason), I may be able to offer a set of wrappers which makes the runtime appear to be object oriented; but I would not recommend this as the ideal approach. Also, my code is wholly dependent on the NeXT runtime environment, so it would need to be adapted (not to mention completed).
Suggestion for Proxy hierarchy:
Currently, NeXT has only one class of object proxy, "NXProxy." NXProxy is its own root in a new hierarchy, but it is intended for use as a Distributed Object proxy. This approach is very short-sighted as there are actually many needs for different types of proxies (we use three different types of proxy for three very different purposes here at WilTel).
I propose that the gnu Object hierrarchy come with a parallel hierarchy called proxy_Object. The proxy_Object class is a complete re-implementation of the Object class in which every method (except forward::) is renamed to "proxy_methodName:" where methodName: is the corresponding name in the Object class. The proxy_Object class would serve as the superclass to all proxy classes and those application-specific proxy subclasses should add their own behavior. This way, the programmer can communicate directly with the proxy by using the "proxy_" convention and all proxies would have a common ancestor.
NOTE: NeXT's (and WilTel's) current approach to proxies is the brute force approach (ie depends on forward::). I believe the proxy concept is powerful enough to warrant a completly fresh approach and possible inclusion in the language itself. A clever implemention of objc_msgSend() could take proxies into consideration and, with some minor additional syntax, programmers could communicate with proxies or the actual target in a much more efficient way. If the language itself were aware of the proxy concept, there would be no reason to implement the proxy_Object hierarchy as a parallel universe. Here's some possible syntax which would tell objc_msgSend() how to do its lookup:
//Send a message to the proxy itself
[someProxy @proxyMsg(doSomething)];
//Send a message intended for the target of the proxy
[someProxy doSomething];
//Send a message to the real thing
[someRealObject doSomething];
If done properly, this could avoid the inefficient practice of using forward::. Perhaps a class which conformsTo: the "Proxy" protocol would be treated as a proxy by objc_msgSend(), else its treated as the real thing. The "Proxy" protocol might define a single method which does whatever forward:: would otherwise do.
